Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9704/000007_owner-urn-ietf _Wed Apr 2 17:25:32 1997.msg

Internet Message Format | 1997-04-30 | 6KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id RAA29635
    for urn-ietf-out; Wed, 2 Apr 1997 17:25:32 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id RAA29630
    for <[e-mail]>; Wed, 2 Apr 1997 17:25:24 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21946  (mail destined for [e-mail]); Wed, 2 Apr 97 17:25:22 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id QAA09344; Wed, 2 Apr 1997 16:25:24 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id QAA15489; Wed, 2 Apr 1997 16:25:19 -0600 (CST)
Date: Wed, 2 Apr 1997 16:25:19 -0600 (CST)
Message-Id: <[e-mail]>
To: "Ryan Moats" <[e-mail]>
Cc: "Daniel LaLiberte" <[e-mail]>,
        "[e-mail]" <[e-mail]>
Subject: Re: [URN] urn: prefix is a brand name?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Ryan Moats writes:
 > On Wed, 2 Apr 1997 13:57:00 -0600 (CST), Daniel LaLiberte wrote:
 > >So that's how it happened.  The previous time I had checked the
 > >syntax, the "urn:" was still optional, as I recall.  I don't recall
 > >any explicit statement to the mailing list that "we are now going to
 > >make 'urn:' required - any comments?".  Oh well, you wanted a brand
 > >name to protect, so you got it.
 >
 > In fact, I take umbrage at the implication of the first sentence, because
 > that is NOT "how it happened".

I meant that's how it slipped past me.  But I apologize for my
unintended slur.

 >  As to the explicit statement about the "urn:" becoming required,
 > there was one and it is in the archives.

My mistake.  I missed it.

But nevertheless, I argue the concepts, not the letter of the specs.
If I can't convince people at the level of concepts, there is no point
arguing the specs.  I would make a very intolerant lawyer.

 > >E.g. web clients do, in fact, use things besides HTTP in resolving
 > >http URLs.  They are not prohibited from doing so.  It doesn't help
 > >to deny this.
 >
 > I assume that you are stating that they do something other
 > than do a DNS lookup of the name and connect with HTTP.

Actually, DNS lookup is part of it, and that should be a hint of
other things.  But browsers do much more.  I listed several things in
an earlier longer message.  Here is what I wrote in summarizing it:

------

Here is an abbreviated version of my list of possible ways to discover the
semantics of a URI.  Only item 4 is possibly non-compliant.  The rest
are actually done and in compliance as far as I know.

1. Look up the URI in an in-memory cache.

2. Look up the URI in local or remote cache services.

3. Look up the URI in a local table that maps a prefix of the URI to
   some protocol or process.

4. If the URI has a DNS component, lookup the domain name for a
   protocol/service mapping.

5. Ask the named service (discovered by any of the above) to resolve the
   URI and learn that some other service or protocol should be used.

6. Get a redirection to another URI or a collection of alternative URIs.

------

A few additional notes.  Item 4 is compliant too.  Anything is.  It's
just not done as far as I know.  Note this is not just looking up the
IP number for the domain name in a URI - this is asking DNS for a
reference to a protocol or service that should be used to resolve the
URI.  Item 3 might look up the resource in a local file system or via
nfs or afs if a prefix of the URI is recognized.

 > If so, I have a hard time reconciling this with RFC 1738, which
 > states that "The <tag> URL scheme is used to designate Internet
 > resources accessible using the <tag> protocol", where
 > <tag> is FTP, Gopher, HTTP.

Read that carefully.  The resources are "accessible using the <tag>
protocol".  "Accessible" doesn't mean you must use only that protocol
- it means you *can* use it.  But, in fact, it is a lie if the
resource is no longer there.

 > As an extension, if a browser isn't following this, then why can't it
 > be claimed that that browser is not supporting the proposed standard
 > and is therefore a BAD thing?

Generally, clients can do anything they can get away with - anything
that their users find useful.  Clients can't get away with talking to
servers in a way that they don't understand because it is not useful,
so clients are really limited to doing things that servers understand,
but there are no limits on *which* servers a client talks to.

 > If you build an RDS mechanism into the browser, then I claim it to be
 > a URN-aware browser, rather than just a URL-aware browser.  I should
 > have been more specific here.

The distinction becomes meaningless when the RDS mechanism
is used to resolve URLs as well as these new "urn:"s.

 > [The rest of the mail has been deleted because I read Dan's statements
 > to be agreeing with mine, but I may be wrong]

You never know with names. :-)  Most controversial is:

I agree, and that is why "urn:" would eventually become associated
with a single protocol, just as most URL schemes are associated with a
       ^^^^^^
single protocol.

dan